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KffilB QD FOR CQNTOOLLING THE TRAFFIC IN AN ATM N ETWORK SO AS TO MAINTAIN THE QUALITY OF 
SERVTPF ■ ^- ■ t—Jis 



Field of the invention 

5 

The present invention relates to a method for controlling 
the traffic in an ATM (Asynchronous Transfer Mode) net- 
work so as to maintain the Quality of Service (QoS) 
thereof by ixnplementing Usage Parameter Control (UPC) 

10 comprising at least one leaky bucket unit arranged be- 
tween an original cell flow of ATM-cells and a switch 
^ unit, there being used one counter for each bucket per 
connection, said coxmters being incremented and decre- 
mented according to predetermine criteria by means of 

15 timer counter means. 

It is to be understood that the present invention finds 
particular application in connection with billing and 
policing in ATM based networks. 



Technical background 
THE PROBLEM 

A widely used method for allocating resources in an ATM 
25 network is to base the allocation on the PCR (Peak Cell 
Rate) and the SCR (Sustainable Cell Rate) . The values for 
PCR and SCR are provided by the user of the ATM network 
during the connection establishment. The values given for 
PCR and SCR are part of the traffic contract for the 
3 0 given connection. To maintain the QoS on the user's and 
all the other ATM connections in the network, it is 
important that the traffic from the users does not exceed 
their PCR and SCR. The action taken to ensure that the 
traffic from the users is conform with the traffic con- 
35 tract is called the Usage Parameter Control (UPC) . A 

method for implementing UPC is with a leaky bucket. The 
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idea behind a leaky bucket is shown in ATM Forum's "User- 
Network Interface Specification" [1]. For Constant Bit 
Rate (CBR) traffic the UPC can consist of a single leaky 



bucket 



Figure 1 illustrates a single Leaky Bucket arrangement. 
The bucket is filled according to the bit rate of the 
traffic sent by the user. It is emptied at fixed time 
intervals. The size of the bucket is dependent on i.e. 
the PGR and CDV (Cell Delay Variation) . 



The leaky bucket is used to check if the user's traffic 
is compliant to its PGR, including the possibility of 
cell delay variation within an agreed bound. For Variable 
Bit Rate (VBR) it is proposed that the UPC consists of a 
dual leaky bucket. The task for the dual leaky bucket is 
to check that the traffic sent by the user is conform to 
the combination of PCR, CDV and SCR, BT (Burst Tolerance 
(BT) is the maximum burst size that can be sent at the 
20 SCR) . 

A dual leaky bucket is implemented with two buckets, one 
for checking PCR and CDV, and one for SCR and BT. When 
overflow occurs in one of the buckets, the traffic from 
the user is considered non conforming to the traffic 
contract. According to the specific network implementa- 
tion the appropriate action is taken. 



Figure 2 illustrates an arrangement wherein the leaky 
bucket (single or dual) is placed in front of the switch- 
ing \init. 



35 



The problem with both the single and the dual leaky 
bucket is to implement them in real time systems. When 
the number of connections is large and a high bandwidth 
is used, there may be difficulties in having time to 
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perform the various calculations (i.e. compute new bucket 
values) . This is especially a problem when implementing a 
dual leaky bucket, which requires even more confutations. 

5 Known solutions 

One method for implementing a dual leaky bucket is to 
have two buckets in_p^araJJ^el . There is one counter for 
each bucket per connection. These bucket counters are 

10 incremented every time a cell for that connections ar- 
rives, and it is checked whether the bucket counters are 
larger than some predefined threshold values. If one of 
the counter values is above its threshold, the cell is 
either tagged, or thrown. At regular time intervals, each 

15 bucket counter for all the connections is decremented 

according to a decrement value specific for each channel 
and bucket . 

Another method for implementing a dual leaky bucket is to 
20 have two bucket counters for each connection. This method 
uses the same mechanism for incrementing the buckets as 
described above. The difference is that with this method 
the bucket counters for connections are not decremented) 



at regular time intervals, only when a cell for that 
25 connection is received. To obtain a true value in each of 
the buckets, a time coiinter is used for each connection. 
The time coimters holds the last time the bucket counters 
for their connection were updated. 

30 Problems with known solutions 

The problem with the first method is that the process of 
decrementing all the bucket counters at regular time 
intervals is time consuming. When the number of connec- 
3 5 tions is large, high bandwidth is supported, and the time 
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between each decrement is small, it may be impossible to 
have time for all these calculations. 

In the second method the number of calculations is 
5 largely decreased. One problem by using this method is 
that you need an extra counter for each connection (the 
time counter) . This can be a problem when the number of 
supported connection is high. The biggest problem with 
this method is the size of the time counter. When high 

10 bandwidths are supported the time counters have to be 

very accurate. The problem arises when a connection with 
much lower bandwidth than the maximum allowed bandwidth 
is policed. Because of the low bandwidth, cells for these 
connections arrive at a much higher interval than cells 

15 belonging to connections of much higher bandwidth. If the 
time counter is not large enough, overflow in the time 
counter can occur. This can lead to that cells that are 
conform with the traffic contract are discarded because 
an overflow in the time counter has occurred. 

20 

US 5 524 006 (Hluchyj et al . ) relates to a second-order 
leaky bucket device and method for traffic management in 
cell relay networks, wherein the second-order leaky 
bucket system is utilized in connection with a peak cell 
25 rate (PGR) leaky bucket, for thereby substantially pro- 
viding a predetermind quality of service. 

EP-0 658 999-A2 (Dighe/NEC corporation) relates to an ATM 
network wherein the data frames of the system are con- 
30 trolled by use of ^^Dual Leaky Bucket" principle. 

US 5 295 13 5 (Kammerl) relates to an arrangement for 
monitoring the bit rate in ATM networks, wherein the bit 
rate is monitored and controlled by means of "Dual Leaky 
35 Bucket" principle. 
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OS 5 289 462 (Ahmadi et al . ) relates to traffic manage- 
ment in packet communications networks ^ wherein the 
parameters of a leaky bucket'' are calculated by using a 
traffic metric system. 

5 

Objects of the invention 

An object of the present invention is to provide a method 
wherein the dual leaky bucket principle can be imple- 
10 mented in a more efficient manner. 

Another object of the present invention is to provide a 
method wherein decrementing of bucket counters can be 
effected as a simple and fast process. 

15 

Yet another object of the present invention is to provide 
a method wherein the priority of the buckets involved are 
utilised in a far more expedient manner. 

2 0 Still another object of the present invention is to 

provide a method wherein the amount of needed computa- 
tions are reduced substantially. 

Yet another object of the present invention is to provide 
25 a method requiring less storage capacity and only one 
single time counter for all connections . 

Still another object of the invention is to provide a 
method in which the decrement factor can be chosen in a 
30 more versatile manner so as to obtain better granularity 
of the system involved. 
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Brief sximmary of the invention 

The above objects are achieved in a method as claimed in 
the preamble, which according to the present invention is 
5 charachterized by the combination of the following steps: 

- decrementing the bucket counters at regular intervals 
but only when there are no arriving cells, and 

- computing real bucket values for a connection when a 
cell for said connection arrives . 

10 

More specifically, said combination of steps are used in 
connection with two buckets which are arranged in the 
same- process but given different priority, said two 
buckets preferably being arranged in series. 

15 

Consequently, by placing the two buckets into the same 
process the amount of needed computations will be low- 
ered. 

20 Further, according to the present invention there is used 
only a single time counter for all connections involved, 
rendering the system even more favourable as regards 
computation time and accuracy. 

25 Still further, by giving the different buckets different 
priority, still more time will be available for decre- 
menting said buckets since the wasting of cells at a 
first bucket will allow more time for the system for 
decrementing the buckets involved. 

30 

Further features and advantages of the present invention 
will appear from the following description taken in 
connection with the appended drawings, as well as from 
the enclosed patent claims. 
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Brief disclosure of the drawings 

Fig, 1 is a simplified diagram illustrating the principle 
of a single leaky bucket arrangement, the bucket here 
5 being filled according to the bit rate of the traffic 
sent by the user. 

Fig. 2 is a schematical diagram illustrating an arrange- 
ment of a prior art leaky bucket principle, it being 
10 single or dual, and being placed in the front of an 
associated switching unit. 

Fig. 3 is a schematical diagram illustrating a prior art 
implementation of a dual leak bucket arrangement. 



Fig. 4 is a schematical diagram illustrating an embodi- 
ment of a method according to the present invention, 
wherein the dual bucket principle has been implemented in 
the process for lowering the amount of needed computa- 
20 tions . 

Fig. 5 is a schematical block diagram illustrating an 
embodiment for implementing the invention, said figure 
comprising the main elements included in a dual leaky 
25 bucket unit substantially as illustrated in Fig. 2. 

Fig. 6 is a flow sheet illustrating the various steps 
taken according to the present method in order to incre- 
ment for exaitple SCR and PGR buckets. 



Fig, 7 is a flow diagram illustrating the steps involved 
according to the present method in order to decrement a 
PGR and SCR bucket involved therein. 
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Detailed description of embodiments 

It is to be understood that the present method as been 
developed in connection with principally a dual leaky 
5 bucket arrangement, but it is to be understood that the 
principle of the present invention can also be applicable 
to any number of buckets operating in accordance there- 
wi th. 

10 As mentioned previously. Fig. 1 illustrates a single 

leaky bucket arrangement according to the prior art. The 
bucket is filled according to the bit rate of the traffic 
sent by the user, and it is, according to prior art, 
emptied at fixed time intervals. The size of the bucket 

15 is dependent on i.e. the Peak Cell Rate (PGR) and the 
Cell Delay Variation (CDV) . 

In Fig. 2 there is illustrated a leaky bucket arrangement 
including single or dual buckets, said buckets being 
20 placed in front of the associated switching unit. 

In Fig. 3 there is illustrated an exan^le of how a prior 
art arrangement can be implemented, i.e. how a new cell 
is arrived firstly at the PGR Peak Cell Rate bucket for 

25 being checked whether compliant with the filling degree 
thereof, and thereafter the same new cell is controlled 
by the SCR Sustainable Cell Rate bucket for being checked 
to be compliant with also the filling degree thereof, 
whereafter any non-compliant signal from both buckets are 

30 sent to a decision circuit for making the decision to 

drop a cell and allow for a new cell to be controlled, or 
for the passing of said do\ible controlled cell to be 
transmitted via said switching unit. 

35 The arrangement according to Fig. 3 illustrates two 

buckets in parallel requiring one counter for each bucket 
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per connection, and the associated bucket coiinters are 
incremented every time a cell for that connection ar- 
rives, and it is also checked whether the bucket counters 
are larger than some predefined threshold values . 

5 

According to this prior art arrangement each bucket 
counter for all the connections is decremented according 
to a decrement value specific for each channel and 
bucket . 

10 

As mentioned previously, another prior art method for 
implementing such a dual leaky bucket is to have two 
bucket counters for each connection, but with this method 
the bucket counters for connections are not decremented 

15 at regular time intervals, only when a cell for that 

connection is received. To obtain a true value in each of 
the buckets a time counter must be used for each connec- 
tion, said time coxinters holding the last time the bucket 
covmters for the associated connection were updated. 

20 Now, turning to Fig. 4, there is illustrated an embodi- 
ment of a method according to the present invention which 
involves a series of advantages compared with the above 
described prior art. 

25 In other words, the present invention is a solution for 

implementing a dual leaky bucket efficiently. This inven- 
tion follows some of the principles from [2], but it 
extends this method to support not only one, but two 
leaky buckets (called a dual leaky bucket). The idea is: 

30 

• Decrement the bucket counters at regular intervals 
(but only when there are no arriving cells) . 

• Compute real bucket values for a connection, when a 
35 cell for that specific connection arrives. 
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• Place the two buckets into the same process to lower 
the amoxint of needed computations. 

• When using two or more buckets the buckets are ar- 
5 ranged in series according to priority. 

With reference to the enclosed Figures 4-7 and the en- 
closed appendix A there will be now given a detailed 
description of an example of an embodiment according to 
10 the present invention. 

Firstly, reference is made to Fig. 4 illustrating a 
simplified basic diagram of an eiT±)odiment according to 
the present invention, whereas Fig. 5 illustrates sche- 
15 matically an embodiment of a dual lealcy bucket xinit, 

substantially as illustrated in Fig. 2, but rearranged 
according to the method of the invention. 

The parameters used in the following figures . 

The maximum n\imber of different connections. 
Time counter, incremented each cell interval 
modulo M. 

The connection number. 

Decrement factor. This is the same for all the 
buckets and connections. The chosen value for 
D gives you the granularity of the system. 

- Increment factor of the PGR bucket for 
connection n. 

I^^n = bandwidth * (D/PCR) . 

- The real value of the PGR bucket for 
connection n. F^^^n is calculated every time a 
cell belonging to connection n is received. 
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^PCR^ " The virtual value of the PGR bucket for 

connection n. L^^n is incremented by when 
a cell for connection n is accepted. It is 
decremented by D*M every M'th cell. 

5 

rpPCR^ - The threshold value of the PGR bucket for 

connection n . 

= requested bandwidth * GDV 

10 l^^n - Increment factor of the SCR bucket for 

connection n. 

X^^\ = bandwidth * (D/SCR) . 



F^^n - The real value of the PGR bucket for 



15 connection n. » is calculated every time a 

cell belonging to connection n is received. 

- The virtual value of the PGR bucket for 

connection n. L^^\ is incremented by X^^\ when 
20 a cell for connection n is accepted. It is 

decremented by D*M every M'th cell. 

T^^\ - The threshold value of the PGR bucket for 

connection n. 
25 T^^a = requested bandwidth * BT. 



Description of Figures 4 and 5 



Firstly, a cell is read from the Buffer-IN to the One 
3 0 cell buffer (marked O in figure 5) . The One cell buffer 
gets the VPI and VGI from the cell, and finds its connec- 
tion number in the connection table. The One cell buffer 
then inserts the right connection nxamber in n (marked © 
in figure 5) . The Logical Dual Leaky bucket Unit then 
35 reads the connection number from n. Then it reads the 



wo 99/25148 ^ ^ PCT/NO98/00298 

12 

counter values related to connection n from the Counter 
Table (marked O in figure 5) . The Logical Dual Leaky 
Bucket Unit then calculates if the cell is compliant with 
the traffic contract (marked O in figure 5) . When the 
calculation is finished, the Logical Dual Leaky Bucket 
Unit sends the new computed counter values to Counter 
Table (marked 6 in figure 5). If the cell is compliant, 
the Logical Dual Leaky Bucket sends a Send Cell signal to 
the One cell buffer (marked © in figure 5) . If the cell 
is not compliant, the Logical Dual Leaky Bucket sends a 
Not Send Cell signal to the One cell buffer, if the One 
cell buffer received a Send Cell signal from the Logical 
Dual Leaky Bucket, it passes the cell to the Buffer-OUT 
(marked O in figure 5). It then reads a new cell from the 
15 Buffer-IN. If the One cell buffer received a Not Send 

Cell sign,al from the Logical Dual Leaky Bucket Unit, it 
reads a new cell from the Buffer-IN that overwrites the 
old cell. 
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In the enclosed Figures 6 and 7, the algorithm used to 
compute whether a cell is compliant to the traffic con- 
tract or not is shown. This algorithm is placed inside 
the Logical Dual Leaky Bucket Unit in Figure 4. 

The new steps (those exceeding [2]) for supporting a dual 
leaky bucket will be shown in bold. 

It is to be understood that Fig. 6 illustrates the steps 
necessary to be taken according to the invention in order 
to increment the SCR and PCR buckets involved in the 
present embodiment . 



35 



Fig. 7 illustrates the steps necessary to be taken in the 
illustrated embodiment in order to decrement the associ- 
ated PCR and SCR bucket. 
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Figure 6 shows in a flow diagram the method for incre- 
menting the PGR and SCR bucket. After a specific time 
interval the process checks if a cell is waiting to be 
processed. If there is no cell waiting, the process goes 
5 to the decrement bucket state (see figure 7) , If a new 
cell has arrived, the real value for the PGR bucket is 
calculated. This value is placed in F^^^. The process then 
checks whether the real value (located in F^^^) is greater 
than the maximum allowed PGR bucket value, T^^^. If the 

10 real PGR bucket value is greater than the threshold 

value, a Not Send Cell signal is sent to the One cell 
buffer (see figure 6) . The process then goes to state 
Decrement bucket (see figure 7) . If the real PGR bucket 
value is equal or lower than the threshold value, the 

15 virtual value of the PGR bucket, , is incremented by 

I^^^. After the process has incremented the virtual value 
of the PGR bucket, it calculates the real value of the 
SGR bucket. This value is placed in F^^^. It then checks 
whether F^^ is greater than T^^. If the real value is 

20 greater than the threshold value, a Not Send Cell signal 
is sent to the One Cell buffer (see figure 5) • If the 
real value of the SGR bucket is equal or lower than its 
threshold value, the virtual value of the SGR bucket, 
li^^^, is calculated. A Send Cell signal is sent to the One 

25 cell buffer (see figure 5), and the process goes to the 
Decrement bucket state (see figure 7) . 

In Figure 7 the method for decrementing the buckets is 
shown. The first thing the process does is to increment 
3 0 the time counter m. The process then calculates the 

virtual value of the PGR and SGR bucket for connection 
number m. After this calculation the process goes to the 
Idle state. 

35 A pseudo code example of an implementation of the method 
is shown in the enclosed Appendix A. This code is written 
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with emphasis on clarity, it is possible to run the 
calculation of a single bucket twice to decrease the 
program size 

5 ADVANTAGES 

With this invention, the number of computations is de- 
creased, because not all buckets are decreased at regular 
time intervals. This method also resolves the time coxm- 

10 ter size problem, because buckets coiinters are decreased 
even though no cell has arrived on their connection. This 
method also requires less storage capacity because it 
only uses a single time counter for all the connections. 
This method for implementing a dual leaky bucket combines 

15 the two buckets in one process, it therefor lowers the 
amount of computations and overhead even more. 

BROADENING 

20 This method for implementing a dual leaky bucket can also 
be used as a single leaky bucket. You only have to set 
the increment value of the second bucket to zero. 

REFERENCES 

25 
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